Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0055/523.txt

Text File | 1997-04-16 | 10KB | 258 lines

Via:      UK.AC.EARN-RELAY; 16 OCT 89 10:58:21 GMT
Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 6599; Sun, 15
          Oct 89 22:13:04 BS
Received: from CEARN.cern.ch by UKACRL.BITNET (Mailer X1.25) with BSMTP id
          4741; Sun, 15 Oct 89 22:13:03 B
Received: by CEARN (Mailer R2.03B) id 2128; Sun, 15 Oct 89 22:13:24 GVA
Date:     Sun, 15 Oct 89 15:00:11 MDT
Reply-To: [e-mail]-SIMTEL20
Sender:   INFO-ATARI16 Discussion <[e-mail]>
Comments: Warning -- original Sender: tag was INFO-A16@MARIST
From:     [e-mail]-SIMTEL20
Subject:  INFO-ATARI16 Digest V89 #523
Comments: To: [e-mail]

INFO-ATARI16 Digest         Sun, 15 Oct 89       Volume 89 : Issue 523

Today's Topics:
                      Laser C and FAST Problems
                      SQL Database Access from C
                            TOS problem ?
----------------------------------------------------------------------

Date: 15 Oct 89 19:16:59 GMT
From:
 gem.mps.ohio-state.edu!usc!merlin.usc.edu!nunki.usc.edu![e-mail]-stat
e.edu  (John Jung)
Subject: Laser C and FAST Problems

  I have a question for all you hard drive and Laser C owners out there.

  Recently, I got an ICD FAST 50 meg hard drive. It performs fine, with the
exception that I can't run any software off the floppy (a 1040STfm) unless the
hard drive is on, and I disable the HD (using Shift-Control-Alt). Other people
have told me that the controller is a little flaky for this reason, but I'm not
worrying about it much, because it's only a slight hassle.

  Now for my problem. I have Laser C 2.0 on the hard drive, and I use it fairly
frequently. The problem is, whenever I do hard drive access with Laser C,
occassionally, the mouse will die on me, in that I can't move the mouse
pointer. Sometimes, the mouse's death is only minor, and I can use the keyboard
controls to control the pointer and leave Laser C, and sometimes the death is
major and nothing will move the mouse, in which case I simply have to reboot
the whole system.

  I have noticed that before the mouse dies, a string of characters (same
character in the string, but not the same character all the time) comes out on
the active Laser C window, and then Laser C pops up a dialog saying that I
should hit a key that is recognized by Laser C. Then the mouse dies.

  The mouse dying only happens with Laser C and not with other programs I use,
like Flash! or WordUp!.

  I use Superboot 5.5A along with the other ICD utilities (clock and boot up
program) to boot up my system. Also, I have no busy light (I can't get it to
work), and the hard drive seems to do occassional disk access, but I'm not
sure.

  What I want to know, is : Is this problem with Laser C common with other HD
users? With other FAST users? Or is it that my HD controller is flakier than I
thought, and that's what's causing all the problems (HD has to be on, to run
floppy, random HD access, and Laser C mouse death)? Or do I have an HD virus?

  Please post or E-mail and help you can give.

                        John

------------------------------

Date: 15 Oct 89 18:13:28 GMT
From: galaxy.rutgers.edu!argus![e-mail]  (Ron DeBlock)
Subject: SQL Database Access from C

A few days ago, I promised to post an article demostrating how to
use Regent Software's SQL Add-On with C.  Sorry for the delay -
my ST was at my dealer getting TOS 1.4 installed (yay!).

I needed a cheap database for a school project, and I found SQL Add-On
in E. Arthur Brown's catalog for $24.95.  I preferred something I could
use with Mark Williams C, but decided that GFA Basic would be OK.

The SQL Add-On works well, but the documentation is not great and the
SQL is not standard.  Syntax is slightly different and it has a funky
way of dealing with queries returning multiple rows.  However, the
price is right.

Regent claims that files are compatible with RegentBase.  It is
supposed to work with GFA Basic V2 and V3.

The Add-On is a terminate-and-stay-resident program (TSR).  It loads
the SQL processor and adds a new xbios call (xbios(500)).  It takes up
over 300 K of ram (buffers, I guess).

To use the Add-On, run the TSR program first.  Use GFA Basic's xbios()
call to call xbios(500).  This returns the address of the SQL processing
function.   The GFA Call function is then used to execute SQL statements.

I reasoned that there is nothing preventing me from doing the same thing
in Mark Williams C.  In C, if you know the address of a function, you
can call it.

By reading the GFA Basic and MWC manuals, and spending some time with the
MWC debugger, I worked it out.  The SQL function expects two arguments
on the stack:
    number of arguments (int, on top of stack)
    arguement buffer (pointer to array of pointers to char buffers)

Below is a sample C program with comments.  Feel free to email if you have
questions (email may no work - post here or use snail mail in that case).


Regent Software
PO Box 14628
Long Beach, CA 90803-1208
[phone]

E. Arthur Brown
3404 Pawnee Drive
Alexandria, MN 56308
[phone]

-----------------------------------------

/*
   Demonstration of using Regent SQL Add-On for GFA Basic with Mark Williams
   C.

   Copyright 1989 by Ronald J. DeBlock, Jr.
   May be used or distributed freely as long as this copyright notice
   is included.
*/

#include <stdio.h>

main()
?
    /* pointer to function */
    typedef void (*PFI)();

    extern long xbios();

    /* sql is a pointer to a function returning void */
    PFI sql;

    /* these char arrays hold arguments for the sql call */
    /* fields */
    char field1[21], field2[3], field3[21];
    /* error code */
    char error[10];
    /* command string */
    char command[100];

    /* this array will hold pointers to the command, error and field
    arguments.  Make the array larger if more fields are used. */
    char *args[5];

    /* the first field in the array points to SQL command string */
    args[0] = command;
    /* second points to a buffer used to return error codes */
    args[1] = error;
    /* all other fields point to buffers where the column results
       of a query will be placed - one buffer per culumn returned */
    args[2] = field1;
    args[3] = field2;
    args[4] = field3;

    /* A program is run before the SQL Add-On can be used.  It
       loads the SQL processor and creates a new xbios call.
       The new xbios call returns the address of the SQL processing
       routine. */
    sql = (PFI)xbios(500);
    printf("sql = %U\n",(long)sql);


    /* This program assumes that a table has been created using the
       SQL statement
         CREATE TABLE phonelist name CHAR(20), age INT(2),
            phone CHAR(20);
      and some records have been added.  The demo program included with
      the product (written in GFA Basic) will do this.  */

    /* set up the command string - SELECT [1] is Regent's funky
       way of setting up a cursor */
    strcpy(command,"SELECT [1] * FROM phonelist;");

    /* Call the SQL processor.  The function expects to see the
    number of arguments on the top of the stack, followed by a
    pointer to the argument array.
        *** WARNING ***
    This is compiler dependent!! Mark Williams C pushes arguments
    right to left.  Your compiler may differ.  If so, reverse the
    order of the arguments and it should work. */

    (*sql)(5,args);
    printf("error: %s\n",error);
    printf("%s   %s   %s\n",field1, field2, field3);

    /* execute another commend to retrieve the next row.
       SELECT NEXT is Regent's funky way of dealing with cursors */
    strcpy(command,"SELECT NEXT * FROM phonelist;");
    (*sql)(5,args);
    printf("error: %s\n",error);
    printf("%s   %s   %s\n",field1, field2, field3);
?


-------------------------------------
--
Ron DeBlock    N2JSO
Net: ...!rutgers!galaxy!argus
US Mail: 42 Davis Street, Phillibsburg, NJ 08865 USA

------------------------------

Date: 15 Oct 89 15:29:10 GMT
From: mcsun!hp4nl!ruuinf![e-mail]  (Piet van Oostrum)
Subject: TOS problem ?

I encountered a strange TOS behaviour (TOS 1.2):

I Fcreate a file, then Fopen the same file (not very usual, I agree). I get
two filehandles of course. I only use the second one, and write some bytes
to the file. Finally I close the second handle, and forget to close the
first one, (or close that last). Result: an empty file. If the first
filehandle is closed first, no problem.

My guess is that the close on the first filehandle (either implicit or
explicit) remembers that nothing has been written on this handle, so the
file should be empty (???)

Note: the compiler has long ints (GCC).

Any comments? Is this a bug? Here is the program:

------------------------------------------------------------------------
#include <osbind.h>
char fname[] = "test.fil";
char message[] = "this is a line\n";
main()
?
    int fd1, fd2, r;

    fd1 = Fcreate(fname, 0);
    fd2 = Fopen(fname, 1);
    r = Fwrite(fd2, strlen(message), message);
    printf ("fd1=%d,fd2=%d,result=%d\n",fd1,fd2,r);
    Fclose (fd2);
    Fclose (fd1); /* or just delete this line */
?
--------------------------------------------------------------------------
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht,  The Netherlands.
Telephone: [phone]      Internet: [e-mail]
Telefax:   [phone]      Uucp: uunet!mcsun!hp4nl!ruuinf!piet

------------------------------

End of INFO-ATARI16 Digest V89 Issue #523
*****************************************